S09-05 MySQL-存储引擎与视图

[TOC]

存储引擎

MySQL 采用插件式存储引擎架构（Pluggable Storage Engine Architecture），将数据的物理存储、提取和索引管理与上层的 SQL 解析、优化及执行器解耦。存储引擎的作用粒度是表级别，同一个数据库实例中的不同数据表可以根据具体的业务场景指定不同的存储引擎。

引擎概述

~~存储引擎~~是 MySQL 数据库的核心组件，负责数据在内存和磁盘上的组织与读写控制。

表级独立：创建表时可自由指定存储引擎，未显式声明时采用系统默认引擎。
功能解耦：连接池管理、SQL 语法解析、查询优化等上层服务由 Server 层统一处理，底层存储与索引由存储引擎层负责。
灵活替换：支持通过修改表属性随时切换存储引擎，满足不同业务阶段的性能诉求。

引擎分类

主流存储引擎在关键功能与特性上的对照如下：

功能特性	InnoDB	MyISAM	Memory	Archive	CSV
事务支持	支持	不支持	不支持	不支持	不支持
锁粒度	行锁 / 表锁	表锁	表锁	行锁	表锁
MVCC 机制	支持	不支持	不支持	不支持	不支持
外键支持	支持	不支持	不支持	不支持	不支持
存储介质	磁盘	磁盘	内存	磁盘（高压缩）	磁盘（文本）
支持索引	B+Tree / Hash / Full-text	B+Tree / Full-text	Hash / B-Tree	仅自增主键	不支持
崩溃恢复	支持 (Crash-Safe)	不支持	不支持	不支持	不支持

InnoDB

~~InnoDB~~ 是 MySQL 5.5 及更高版本的默认事务型存储引擎，专为高并发读写和数据完整性设计。

核心特性

事务支持：完整支持 ACID 特性，具备基于 Redo Log 的崩溃恢复（Crash-Safe）能力。
锁粒度：支持行级锁（Record Lock、Gap Lock、Next-Key Lock）和表级锁，写并发性能高。
外键约束：支持物理外键（Foreign Key），保证跨表的参照完整性。
并发控制：基于 MVCC（多版本并发控制）实现非阻塞的快照读，大幅提升读写并发性能。
聚簇索引：表数据按主键顺序组织在 B+ 树的叶子节点上，主键查询效率极高。

物理存储

在 MySQL 8.0 中，每张 InnoDB 表默认对应独立的 .ibd 表空间文件，内部包含数据行、索引以及串行化字典信息（SDI）。

适用场景

绝大多数在线事务处理（OLTP）核心业务系统，如电商订单、账户资金、用户中心等涉及频繁并发更新与事务一致性的场景。

MyISAM

~~MyISAM~~ 是 MySQL 5.5 之前的默认存储引擎，属于轻量级的非事务型引擎。

核心特性

无事务与外键：不支持 ACID 事务操作，也不支持物理外键约束。
表级锁定：仅支持表级锁，读写互斥，高并发写操作会阻塞全表的读写请求。
非聚簇索引：索引文件与数据文件分离，主键索引与二级索引的叶子节点均存储指向物理数据行的指针。
快速计数：表元数据中单独维护了行数计数器，在无 WHERE 条件下执行 COUNT(*) 耗时极短。

物理存储

.sdi：表结构元数据文件（MySQL 8.0+）。
.MYD：数据文件（MyISAM Data）。
.MYI：索引文件（MyISAM Index）。

适用场景

以读为主、几乎无修改删除操作、对并发写入和事务无要求的轻量级数据报表或静态配置表。

Memory

~~Memory~~ 引擎（早期称为 HEAP 引擎）将全部数据和索引保存在内存中，读写响应时间极短。

核心特性

纯内存存储：数据常驻内存，服务器重启或崩溃时数据会全部丢失，但表结构定义仍保留在磁盘上。
高效索引：默认支持 HASH 索引（等值查询极快），同时也支持 B-Tree 索引。
表级加锁：并发写操作时存在表级锁竞争，并发写性能受限。
字段限制：不支持 TEXT 和 BLOB 等变长的大对象数据类型。

适用场景

生命周期短暂的高频访问临时数据、字典编码缓存表，以及报表统计过程中的中间计算临时表。

CSV

~~CSV~~ 引擎直接将数据以标准的纯文本 CSV（逗号分隔值）格式组织并保存在磁盘中。

核心特性

可读性强：物理文件为标准的 .csv 文本文件，可直接被 Excel、文本编辑器或第三方脚本工具读取与解析。
不支持索引与事务：没有索引机制，全表扫描开销大；不支持事务与崩溃恢复。
字段非空限制：表内所有列字段必须显式声明为 NOT NULL。

适用场景

异构系统之间的数据批量导入导出、跨平台数据共享或作为临时交换媒介。

特殊引擎

除了上述常用引擎外，MySQL 还提供了一些具备特定网络或架构功能的专用存储引擎：

Blackhole（黑洞引擎）：写入的数据会被直接丢弃（不落盘），但会正常记录 Binlog，常用于主从复制拓扑中的中继过滤与分发节点。
Federated（联邦引擎）：用于跨服务器远程访问其他 MySQL 实例中的数据表，本地仅保存结构定义而不存储实际数据。
NDB Cluster（分布式引擎）：MySQL Cluster 分布式集群专属引擎，支持数据自动分片、高可用内存计算与高容错性。

管理操作

MySQL 的存储引擎管理操作涵盖了存储引擎状态查询、默认引擎设定、建表时引擎指定、已有表引擎转换、插件式引擎装卸以及表空间碎片维护。

引擎查看

通过客户端命令或系统元数据表可以检查当前 MySQL 实例支持的引擎清单及其配置状态。

sql

-- 1. 查看当前实例支持的所有存储引擎及其状态
SHOW ENGINES;

-- 2. 查看指定数据表的存储引擎及基础状态
SHOW TABLE STATUS
  LIKE 'user_info';

-- 3. 通过系统元数据表批量检索所有使用非 InnoDB 引擎的数据表
SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE
  FROM information_schema.TABLES
  WHERE TABLE_SCHEMA = DATABASE()
    AND ENGINE != 'InnoDB';

SHOW ENGINES 核心字段含义

Engine：存储引擎名称（如 InnoDB, MyISAM, Memory 等）。
Support：支持状态。DEFAULT 为当前默认引擎，YES 为已启用，NO 为未启用，DISABLED 为已安装但被禁用。
Transactions：是否支持 ACID 事务。
Savepoints：是否支持事务保存点。

默认配置

当创建表时未显式指定 ENGINE 选项，系统会自动采用 default_storage_engine 变量所指定的存储引擎。

sql

-- 1. 查看当前会话与全局的默认存储引擎
SELECT @@default_storage_engine, @@global.default_storage_engine;

-- 2. 修改当前会话的默认存储引擎（仅对当前连接生效）
SET SESSION default_storage_engine = 'MyISAM';

-- 3. 修改全局默认存储引擎（对新建立的连接生效，服务重启后失效）
SET GLOBAL default_storage_engine = 'InnoDB';

永久生效配置

若要使默认存储引擎在 MySQL 服务重启后依然生效，需修改配置文件（my.cnf 或 my.ini）：

ini

[mysqld]
default-storage-engine = InnoDB

指定引擎

在执行 DDL 语句创建表时，可以通过 ENGINE 子句为表单独指定存储引擎。

sql

-- 1. 创建数据表时显式指定存储引擎与字符集
CREATE TABLE session_cache (
  session_id VARCHAR(64) PRIMARY KEY,
  user_id BIGINT NOT NULL,
  last_active TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) ENGINE = Memory DEFAULT CHARSET = utf8mb4;

表级独立性：同一个数据库内的不同表可以使用不同的存储引擎（例如核心交易表使用 InnoDB，临时高速缓存使用 Memory）。
外键兼容性：若数据表之间存在外键约束关联，关联的两张表均必须使用支持外键的存储引擎（如 InnoDB）。

引擎转换

修改已有数据表的存储引擎会将原表数据导出并按新引擎的物理存储格式重新写入。

sql

-- 1. 方式一：直接修改已有表的存储引擎（触发整表重建）
ALTER TABLE session_cache
  ENGINE = InnoDB;

-- 2. 方式二：通过影子表平滑迁移数据（降低锁表影响）
CREATE TABLE session_cache_new
  LIKE session_cache;
-- 修改影子表的存储引擎
ALTER TABLE session_cache_new
  ENGINE = InnoDB;
-- 批量同步数据
INSERT INTO session_cache_new
  SELECT *
    FROM session_cache;
-- 原子重命名切换数据表
RENAME TABLE session_cache TO session_cache_old, session_cache_new TO session_cache;

转换执行注意事项

引擎特性差异：从 InnoDB 转换到 MyISAM 会丢失事务和物理外键约束；从其他引擎转到 Archive 会导致后续无法执行 UPDATE 和 DELETE。
锁表与 I/O 开销：直接使用 ALTER TABLE 会在转换期间对源表施加读锁，海量数据表推荐使用影子表方式进行分批迁移。
数据类型兼容：某些引擎对字段类型存在限制（如 Memory 引擎早期版本对变长字段 BLOB / TEXT 存在限制）。

插件管理

MySQL 插件式架构支持在运行时动态加载与卸载第三方或专用存储引擎插件，无需停机重新编译。

sql

-- 1. 查看当前已安装的插件与存储引擎状态
SHOW PLUGINS;
-- 2. 动态安装存储引擎动态库插件
INSTALL PLUGIN example
  SONAME 'ha_example.so';
-- 3. 动态卸载指定存储引擎插件
UNINSTALL PLUGIN example;

INSTALL PLUGIN：将系统插件目录中的共享库（.so 或 .dll）加载进内存并在 mysql.plugin 系统表中注册。
UNINSTALL PLUGIN：从运行时环境中卸载插件。若当前有数据表正在使用该引擎，卸载操作会被拒绝。

空间维护

在频繁执行大批量删除、更新操作，或执行过引擎转换之后，表空间内部会产生物理空隙（碎片），需通过空间维护命令进行重组回收。

sql

-- 1. 重构表空间并回收物理磁盘碎片
OPTIMIZE TABLE order_info;
-- 2. 重新分析并收集索引分布统计信息
ANALYZE TABLE order_info;
-- 3. 检查数据表是否存在物理损坏与逻辑错误
CHECK TABLE order_info;

维护机制解析

OPTIMIZE TABLE：对于 InnoDB 表，其底层本质上等价于执行 ALTER TABLE order_info ENGINE = InnoDB;。系统会创建一份新的表空间文件，将有效数据紧凑排列后替换旧文件，从而把释放的空间归还给操作系统（需开启 innodb_file_per_table）。
ANALYZE TABLE：重新采样并计算索引基数（Cardinality），更新统计元数据，帮助查询优化器选择更精准的执行计划。
CHECK TABLE：验证数据行的完整性以及索引项的树形结构是否正常，排查潜在的数据页损坏。

视图

概述

基本概念

~~视图（View）~~ 在 MySQL 中是一种基于 SQL 查询语句构建的“虚拟表”。

视图在逻辑表现上与普通的物理表一致，拥有列名、数据类型和行记录，并支持常规的 SELECT 查询操作。但视图在物理磁盘（.frm）上并不保存任何业务数据行，它仅保存一条预定义的 SQL 查询逻辑。

存储机制

视图与普通基表在底层存储、生命周期和数据维护机制上存在本质区别。

维度	物理基表 (Base Table)	视图 (View)
存储内容	真实的数据行、索引文件、表结构元数据	仅存储视图定义（SQL 文本与结构元数据）
磁盘占用	随数据量增长而线性膨胀	占用空间固定且极小（通常仅几 KB）
数据源头	独立持久化存储	实时依赖底层基表产生
数据同步	无需同步，本身即源数据	基表数据一旦变更，视图查询结果即刻联动
索引支持	直接支持创建 B+Tree、Hash 等物理索引	MySQL 原生不支持物化视图，无法直接在视图上建索引

解析与执行机制

当客户端对视图发起查询时，MySQL 会在内部完成从逻辑定义到物理查询的映射与展开。

text

[ 客户端查询视图 ]
    |
    v
[ 词法/语法解析 (Parser) ]
    |
    v
[ 读取数据字典中的视图定义 ]
    |
    v
[ 合并查询逻辑 / 实例化临时表 ]
    |
    v
[ 优化器生成执行计划 (Optimizer) ]
    |
    v
[ 存储引擎检索基表物理数据 (Engine) ]

语法解析：MySQL 接收到针对视图的 SQL 请求，识别引用的对象为视图。
定义加载：服务层从系统数据字典中读取该视图存储的 SELECT 语句。
语句重写：优化器将外部查询条件与视图内部的 SELECT 逻辑进行合并或构建内部派生表。
计划生成：优化器针对最终生成的查询树计算最优访问路径并选择可用索引。
数据检索：调用底层存储引擎读取物理基表数据并格式化输出给客户端。

基础操作

定义与调用视图遵循标准 DDL 与 DQL 语法规范。

sql

-- 创建基础用户公开信息视图
CREATE VIEW v_user_public AS
  SELECT id, username, email, created_at
  FROM users
  WHERE is_active = 1;

sql

-- 查询视图数据
SELECT username, email
  FROM v_user_public
  WHERE created_at >= '2026-01-01';

sql

-- 删除视图定义（不影响物理基表数据）
DROP VIEW IF EXISTS v_user_public;

核心特性与边界

~~逻辑解耦与安全控制~~

列级与行级权限隔离：可针对视图单独授权，使非特权用户仅能访问指定字段和满足特定条件的行，屏蔽密码、薪资等敏感数据。
屏蔽表结构演进：当底层物理表发生分表、字段重命名或结构拆分时，只需调整视图内部的查询映射，即可保证上层应用代码无感知。

~~性能特征与使用边界~~

无物理加速：MySQL 标准视图不具备物化缓存功能，查询视图的开销等同于执行其底层的 SQL 语句。
嵌套膨胀风险：多层视图嵌套会导致查询重写过于复杂，可能阻碍优化器有效利用基表索引，进而退化为全表扫描或产生庞大的内部临时表。

基础操作

视图生命周期

视图的基础操作涵盖从创建、检索、维护到销毁的完整生命周期。

创建视图

使用 CREATE VIEW 语句创建视图。可以通过 CREATE OR REPLACE VIEW 在同名视图存在时直接覆盖，也可显式定义视图的虚拟列名。

sql

-- 创建或覆盖员工公开信息视图并显式指定字段别名
CREATE OR REPLACE VIEW v_emp_public (emp_id, emp_name, dept_id, entry_date) AS
  SELECT id, name, department_id, hire_date
  FROM employees
  WHERE status = 'ACTIVE';

列名映射：若在视图名称后指定列名列表，其数量必须与 SELECT 投影出的字段数量严格一致；若省略，则默认沿用底层查询的列名或别名。
安全覆盖：使用 CREATE OR REPLACE VIEW 时，若目标视图已存在则直接更新定义，若不存在则新建，避免因重名导致报错。

查询视图

视图创建后，在语法层面上可作为只读或受限的可写数据表，支持常规的条件过滤、排序和关联。

sql

-- 像查询普通物理表一样对视图检索数据
SELECT emp_id, emp_name, entry_date
  FROM v_emp_public
  WHERE entry_date >= '2024-01-01'
  ORDER BY entry_date DESC;

条件合并：外层查询的 WHERE 条件与排序规则会被 MySQL 优化器合并到底层查询中一并执行。
语法一致：客户端查询视图的语法与查询物理基表完全一致，应用程序无感知。

查看视图

查看视图主要用于了解其字段结构、底层 SQL 逻辑以及元数据配置。

sql

-- 查看视图的列结构与字段类型
DESCRIBE v_emp_public;

-- 查看视图的完整创建语句与安全上下文
SHOW CREATE VIEW v_emp_public;

-- 从系统元数据字典中查询视图定义与可更新性
SELECT table_name, view_definition, is_updatable
  FROM information_schema.VIEWS
  WHERE table_schema = DATABASE()
  AND table_name = 'v_emp_public';

text

+-------------------------------------------------------------+
|                      视图信息查看途径                       |
+-------------------------------------------------------------+
| 1. DESCRIBE / DESC        -> 查看列名、字段类型、是否为 NULL |
| 2. SHOW CREATE VIEW       -> 查看原始建表 DDL 及字符集配置  |
| 3. information_schema     -> 系统化检索定义、检查选项及更新属性|
+-------------------------------------------------------------+

修改视图

当底层业务逻辑调整需要重构视图查询时，可以使用 ALTER VIEW 修改现有视图的结构定义。

sql

-- 修改视图定义以追加薪资字段并收紧过滤条件
ALTER VIEW v_emp_public AS
  SELECT id AS emp_id, name AS emp_name, department_id AS dept_id, salary, hire_date AS entry_date
  FROM employees
  WHERE status = 'ACTIVE'
  AND salary > 0;

原子替换：ALTER VIEW 不会删除视图对象本身，仅更新数据字典中保存的 SELECT 文本定义。
权限要求：执行修改操作的用户必须同时具备该视图的 CREATE VIEW 和 DROP 权限，以及底层基表的对应查询权限。

重命名视图

MySQL 没有专门的 RENAME VIEW 语法，视图与物理表共用命名空间，重命名操作通过 RENAME TABLE 实现。

sql

-- 将旧视图名称重命名为新视图名称
RENAME TABLE v_emp_public TO v_emp_active_public;

命名空间共用：视图与表属于同一命名空间，视图名称不能与同一数据库内的任何物理表或其它视图重名。
依赖失效风险：重命名视图后，若存在依赖该视图的其它外层视图或存储过程，相关对象在执行时将抛出找不到对象的错误。

删除视图

当视图不再使用时，可以使用 DROP VIEW 移除视图定义。

sql

-- 批量安全删除一个或多个视图
DROP VIEW IF EXISTS v_emp_active_public, v_dept_summary;

text

[ 执行 DROP VIEW ]
    |
    v
[ 仅从数据字典移除视图定义元数据 ]
    |
    +----------------------------+
    | 底层物理表及业务数据保持完好 |
    +----------------------------+

只删定义：删除视图仅仅移除数据字典中的元数据，完全不会影响或删除底层物理基表中的真实数据。
IF EXISTS 机制：添加 IF EXISTS 子句可在视图不存在时产生 Warning 而不是中断执行报 Error，适合自动化运维脚本。

执行算法

MySQL 在执行针对视图的查询时，由优化器根据视图定义和指定的算法类型（ALGORITHM）决定解析与运行路径。

[ MERGE 模式 ]
外部查询 + 视图定义 ───> 优化器合并为一条 SQL ───> 执行单个查询 ───> 命中基表索引

[ TEMPTABLE 模式 ]
执行视图 SELECT ───> 物理物化生成临时表 ───> 外部查询扫描临时表 ───> 无法使用基表索引

~~三种执行算法对比~~

MERGE（合并算法）：
机制：MySQL 将引用视图的外部查询语句与视图自身的定义语句合并成一条完整的 SQL，直接作用于底层基表。
优势：外部查询的 WHERE 条件能直接下推到基表，充分利用基表上的索引，性能最优。
TEMPTABLE（临时表算法）：
机制：MySQL 先执行视图内部的查询，将结果集物化（Materialize）为内存或磁盘上的临时表，随后外部查询对该临时表进行扫描。
劣势：临时表缺乏基表索引支持，且存在额外的内存与 I/O 开销。
UNDEFINED（未指定/默认算法）：
机制：由 MySQL 优化器自动选择，优先尝试使用 MERGE，若视图结构不支持 MERGE 则自动降级为 TEMPTABLE。

~~强制使用 TEMPTABLE 的场景~~

当视图定义中包含以下构造时，MySQL 无法进行语句合并，必须使用 TEMPTABLE 机制：

聚合函数（如 SUM()、COUNT()、MAX() 等）
DISTINCT 去重关键字
GROUP BY 或 HAVING 子句
UNION 或 UNION ALL 联合查询

SELECT 投影列表中包含子查询

sql

-- 显式指定使用 MERGE 算法构建高性能视图
CREATE ALGORITHM = MERGE VIEW v_high_salary_emp AS
  SELECT
    emp_id, emp_name, salary, dept_id
    FROM employee
    WHERE salary > 10000;

可更新性

部分简单的视图支持对其执行 INSERT、UPDATE、DELETE 等 DML 操作，这些写操作最终会被转换并同步应用到底层基表。

~~可更新视图的必要条件~~

视图若要支持 DML 更新，视图中的行必须与基表中的行存在严格的一对一对应关系。

以下情况下的视图为不可更新视图：

使用了 TEMPTABLE 算法的视图。
包含聚合函数、GROUP BY、HAVING、DISTINCT、UNION 的视图。
处于多表 JOIN 关联中的视图（多表视图通常只允许单表更新，严禁同时修改多个基表，且不可执行 INSERT）。
SELECT 列表中包含常量表达式或派生计算列。

~~检查选项 (WITH CHECK OPTION)~~

为了防止通过视图进行 DML 操作时插入或修改出“在当前视图中不可见”的数据，可以使用 WITH CHECK OPTION 子句进行约束校验。

[ CASCADED 级联检查机制 ]
向 View 2 写入数据
     │
     ▼
 校验 View 2 的 WHERE 条件 ────> 失败则报错回滚
     │ (通过)
     ▼
 递归校验 View 1 的 WHERE 条件 ──> 失败则报错回滚
     │ (通过)
     ▼
  写入基表

CASCADED（级联检查，默认值）：不仅检查当前视图的 WHERE 条件，还会沿着视图引用链向下递归检查所有底层视图的 WHERE 条件，即使底层视图未显式声明 WITH CHECK OPTION。

LOCAL（本地检查）：仅检查当前视图自身的 WHERE 条件；只有当被引用的底层视图也显式定义了 WITH CHECK OPTION 时，才会递归检查该底层视图。

sql

-- 创建带级联检查选项的可更新视图
CREATE VIEW v_active_users AS
  SELECT
    user_id, username, status, score
    FROM users
    WHERE status = 'ACTIVE' AND score >= 60
  WITH CASCADED CHECK OPTION;

-- 尝试将分数更新为 50 会被 CHECK OPTION 拦截并报错
UPDATE v_active_users
  SET score = 50
  WHERE user_id = 1001;

权限安全

视图可以作为安全隔离层，用于实现敏感字段屏蔽、行级权限控制以及权限委派。

~~视图的执行安全上下文~~

MySQL 视图支持通过 SQL SECURITY 属性指定以何种身份权限运行查询：

DEFINER（定义者模式，默认）：视图在执行时使用创建者的权限。
应用场景：数据脱敏。普通用户没有底层敏感基表的访问权限，管理员为其开放特定视图的 SELECT 权限，即可让用户在无底层表权限的情况下读取经过过滤的数据。
INVOKER（调用者模式）：视图在执行时使用当前查询用户的权限。

应用场景：调用者必须同时拥有视图的访问权限以及视图所引用的所有底层基表的对应访问权限，否则查询报错。

sql

-- 创建以调用者权限执行的订单脱敏视图
CREATE SQL SECURITY INVOKER VIEW v_user_orders AS
  SELECT
    order_id,
    user_id,
    amount,
    DATE(created_at) AS order_date
    FROM orders;

生产实践

在生产级数据库架构与复杂业务开发中，合理评估视图的利弊是保障系统吞吐与稳定性的关键。

~~视图的核心价值~~

逻辑数据独立性：当底层物理表发生拆分、重命名或重构时，可以通过调整视图定义保持对外接口不变，降低对上层应用代码的侵入。
统一业务口径：将复杂的多表关联计算（如已支付且未退款的有效订单汇总）封装在视图中，避免各业务线编写重复且不一致的 SQL。
细粒度数据权限隔离：通过隐藏工资、身份证、手机号等涉密列，或添加 WHERE tenant_id = X 实现多租户逻辑切分。

~~性能限制与反模式~~

无原生物化视图：MySQL 官方并不提供像 Oracle 或 PostgreSQL 那样的物化视图（Materialized View），视图每次调用都会实时计算，对于大表聚合视图无法起到缓存物理数据的效果。
禁止“视图套视图”：多层嵌套视图会导致优化器无法进行有效的谓词下推与索引合并，容易退化为大量的临时表全表扫描，造成 CPU 与内存急剧消耗。
避免在 OLTP 核心写路径上使用可更新视图：视图更新的转换逻辑增加了 SQL 解析与约束校验开销，核心高并发交易链路应直接操作基表。

~~元数据管理与排查~~

sql

-- 查询当前库下所有视图的算法定义与更新支持状态
SELECT
  table_name,
  view_definition,
  is_updatable,
  check_option,
  security_type
  FROM information_schema.views
  WHERE table_schema = 'company_db';

S09-05 MySQL-存储引擎与视图 ​

存储引擎 ​

引擎概述 ​

引擎分类 ​

InnoDB ​

MyISAM ​

Memory ​

Archive ​

CSV ​

特殊引擎 ​

管理操作 ​

引擎查看 ​

默认配置 ​

指定引擎 ​

引擎转换 ​

插件管理 ​

空间维护 ​

视图 ​

概述 ​

基本概念 ​

存储机制 ​

解析与执行机制 ​

基础操作 ​

核心特性与边界 ​

基础操作 ​

视图生命周期 ​

创建视图 ​

查询视图 ​

查看视图 ​

修改视图 ​

重命名视图 ​

删除视图 ​

执行算法 ​

可更新性 ​

权限安全 ​

生产实践 ​

S09-05 MySQL-存储引擎与视图

存储引擎

引擎概述

引擎分类

InnoDB

MyISAM

Memory

Archive

CSV

特殊引擎

管理操作

引擎查看

默认配置

指定引擎

引擎转换

插件管理

空间维护

视图

概述

基本概念

存储机制

解析与执行机制

基础操作

核心特性与边界

基础操作

视图生命周期

创建视图

查询视图

查看视图

修改视图

重命名视图

删除视图

执行算法

可更新性

权限安全

生产实践